上一篇討論到壓測腳本通常有現成內容可以改，QA 真正花時間的地方，是壓測結束後要對齊時間、看 metrics、截圖、分析，最後還要寫成報告。

既然想讓 AI 處理這一段，我們就要決定哪些資料需要搜集、資料要怎麼整理，以及報告要呈現什麼內容，最後才有辦法設計出完整的架構。今天就來討論上述的問題。

AI 要寫報告需要哪些資料

一份壓測報告至少需要三類資料：

除了提供數字之外，AI 還需要知道數字的定義。例如「目標 TPS 是 100」，可能代表每秒完成 100 次業務操作，也可能代表每秒送出 100 個 HTTP request。定義沒有寫清楚，後面的分析就可能從一開始便用錯基準。

定義壓測情境與通過門檻

每次壓測原本就會先定義測試情境與通過門檻。例如模擬 100 位使用者同時登入並查詢帳戶資料，持續執行 15 分鐘；測試期間 P95 response time 必須低於 500ms、error rate 低於 1%，TPS 至少達到 100。
把這些資料搜集下來，程式就能根據 metrics 判斷壓測結果是否通過。

所以這些資料應該不難取得。

搜集分析壓測結果需要的資料

一般來說，我們會替服務建立 Grafana dashboard，觀察 Pod 的 CPU、Memory 使用量，以及 JVM heap、GC、Tomcat thread pool 和 connection pool 等 metrics。這些資料可以呈現服務在壓測期間的運行狀況。

程式可以透過 Prometheus API，取得服務在壓測期間與壓測結束後恢復期的 metrics。壓測時間一長，資料點可能會非常多，所以取得資料後還要先做特徵化，整理出後續分析需要的數值與趨勢。

至於 metrics 的取得方式，我想先分成兩類。一類需要觀察整段壓測期間的變化，例如 CPU、Memory 使用量，這類資料會使用 query_range 查詢，依照設定的間隔取得時間序列，再由程式計算最大值、最小值、平均值與資料完整性。另一類只需要整場壓測的統計結果，例如 P95、P99、平均等待時間或 timeout 次數，這類資料可以直接透過 PromQL 計算，不需要取得整段時間序列。

除了執行狀況，也要記錄服務當時的資源條件，例如 Deployment 的 replica 數量、HPA 的 min/max 設定，以及 CPU、Memory 的 request 和 limit。少了這些資料，即使看到 CPU 用量很高，也很難判斷當時配置了多少資源。

程式可以透過 Kubernetes API 取得 Deployment 與 HPA 的設定。如果 Prometheus 已經有搜集對應的 Kubernetes metrics，也可以直接從 Prometheus 查詢。

最後是 k6 的執行結果，包含 TPS、response time 與 error rate。這些黑箱資料可以呈現使用者從外部實際感受到的服務表現。

k6 執行完成後可以產生 JSON summary，程式直接讀取這個檔案，就能取得整場壓測的統計結果。如果還想觀察 TPS、response time 與 error rate 在壓測期間的變化，可以設定 Prometheus Remote Write，讓 k6 在執行期間將 metrics 寫入 Prometheus，再由程式查詢完整的時間序列。

整理並保存壓測相關資料

程式從 Prometheus 查回 metrics 後，還需要保存當時的查詢內容與原始結果。Prometheus 的資料可能會過期，之後就算重新執行相同的查詢，也不一定能拿到當時的結果。所以我們會先建立 Snapshot，記錄實際執行的 PromQL、查詢時間，以及 Prometheus 回傳的完整資料，之後有問題時還能回頭檢查。

Snapshot 保存的是 Prometheus 的查詢內容與結果，裡面還沒有整理出後續分析需要的特徵。因此，程式會先做前面提到的特徵化，區分正式壓測與恢復期的資料，計算最大值、最小值、平均值、發生時間與資料完整性，再將完整時間序列和這些結果保存成 Feature artifact。

完成特徵化後，還要加入 k6 執行結果、驗收條件與服務資訊，最後將這些資料整理成 Bundle。AI 產生報告時，只要讀取 Bundle 就能開始分析壓測結果。

報告圖表

壓測報告免不了要附上圖表，讓讀的人可以看到壓測期間 metrics 的變化。這些圖表可以直接使用前面提到的 Grafana dashboard，再配合文字解釋圖表呈現的狀況，讓整份報告更容易閱讀。

服務雖然已經有 Dashboard，裡面通常會放很多 panel。如果全部截圖放進報告，篇幅會變得很長，也不容易看出重點。所以我希望 AI 可以根據分析結果，從 Dashboard 裡挑選幾個關鍵的 panel，再由程式截圖並放進報告。圖表比較多時，也可以將幾個相關的 panel 合併成一張圖，讓報告更精簡。

報告格式

我們可以先把報告格式設定好，讓 AI 按照固定的章節整理資料，避免每次產出的報告結構不同，最後連重點放在哪裡都不一定。我對 QA 的工作沒有那麼熟，以下章節是我想像中一份壓測報告應該交代的內容，先規劃出來的：

1. 測試概要：說明這次壓測的目的、測試時間、執行環境與最後結果。
2. 服務資訊：記錄服務版本、replica 數量、資源配置與 HPA 設定。
3. 驗收條件與測試結果：列出 TPS、response time、error rate 等通過門檻，並標示各項結果是否通過。
4. 測試情境：說明模擬的使用者行為、流量設定、執行時間與使用的壓測腳本。
5. 實際執行結果：整理 k6 執行結果與服務 metrics，搭配圖表說明壓測期間發生的狀況。
6. 發現與注意事項：記錄測試期間發現的問題、目前的限制，以及後續需要確認的地方。

整體架構

前面的需求都整理完後，整體架構大概會長這樣：

總結

今天把 AI 壓測報告需要的資料、處理方式與整體架構都整理完了。壓測完成後，程式會整理資料並判斷驗收結果，再交給 AI 分析，最後加上圖表產生報告。

架構定下來後，下一篇開始進入實作。

今天就先寫到這，我們明天見！